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1 METHOD, APPARATUS AND SYSTEM PROVIDING 

2 IMPROVED VOICE ROUTING CAPABILITIES 
3 

4 BACKGROUND OF THE INVENTION 

5 

6 I. Field of the Invention 

7 This invention relates broadly to telephone systems and methods. More 



8 particularly, this invention relates to telephone systems that employ both traditional 

9 PSTN-based calls and Internet-based VOIP calls. 
10 

11 2. State of the Art 

1 2 Internet-based VOIP calls are typically less expensive to a user than traditional 

1 3 PSTN-based calls, especially so for long distance calls and international calls. However, 

1 4 the technology utilized to realize the Internet-based VOIP network currently has 

1 5 limitations. For example, the quality-of-service of the Internet-based VOIP network can 

1 6 vary as a result of wide dynamic changes in latency, jitter and/or packet loss of the 

1 7 network, and the connection to the Internet-based VOIP network is unavailable in the 

1 8 event of power failure. Thus, in certain instances, it is preferable to place the call over 

1 9 the traditional public switched telephone network (PSTN). 
20 

21 In order to leverage the lower costs associated with Internet-based VOIP calls and 

22 maintain the guaranteed quality-of-service and reliability of the traditional PSTN calls, 

23 systems have been developed that enable customers to place and receive Internet-based 
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1 calls (i.e., voice over Internet Protocol (VOIP) calls) as well as traditional public 

2 switched telephone network (PSTN) calls. An example of such a system is described in 

3 U.S. Patent 6,404,764 to Jones et al. In this system, a network premises gateway 

4 provides an interface between the POTS telephones of the premises and the PSTN and 

5 Internet. When placing a call, the DTMF detection and call progress generator of the 

6 gateway detects an off-hook condition with a POTS telephone, receives a sequence of 

7 signals generated by the POTS telephone, and buffers this sequence. The gateway 

8 processes the sequence to detect a predetermined sequence that signify a VOIP-based 

9 call. Upon detection, the gateway enters VoIP mode whereby the call is placed over the 

1 0 Internet. If the predetermined sequence is not detected, the gateway enters a POTS mode 

1 1 whereby the buffered sequence is transmitted to the PSTN (i.e., redialed) such that call is 

1 2 placed over the PSTN. For VOIP calls, the gateway system provides analog-to-digital 

1 3 conversion functionality, digital-to-analog conversion functionality and protocol 

1 4 conversion functionality. 
15 

16 In these systems, circuitry is required to intercept and store the dialed number in 

1 7 addition to circuitry to seize the PSTN phone line and redial the number. Such circuitry 

1 8 adds unwanted complexity and costs to the systems. The complexities stem from the fact 

1 9 that the North American and European dialing conventions are highly irregular and 

20 frequently subject to change. 
21 
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1 Moreover, it is imperative that in the advent of a power failure, the POTS 

2 telephones of the premises continue to operate. In such systems, because the POTS lines 

3 are intercepted, this can cause a problem during a power failure. 
4 

5 SUMMARY OF THE INVENTION 

6 

7 It is therefore an object of the invention to provide an 



8 apparatus/methodology/system that routes voice calls over diverse networks (such as the 

9 PSTN, one or more Internet-based VOIP networks, and/or a WATS line) in a manner that 
1 0 does not require interception, storing and redialing the dialed number. 

11 

12 It is another object of the invention to provide such an 

1 3 apparatus/methodology/system that routes voice calls over diverse networks but which 

1 4 maintains a connection of analog telephone lines of the premises to the PSTN such that 

1 5 the POTS service provided by the PSTN enables the telephones to operate in a normal 

1 6 manner in the event of power failure. 
17 

18 It is a further object of the invention to provide such an 

1 9 apparatus/methodology/system that routes calls over the diverse networks in accordance 

20 with one or more routing tables. 
21 
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1 It is also an object of the invention to provide configuration of such routing tables 

2 to minimize telephone usage costs that are attributable to calls placed over the diverse 

3 networks. 
4 

5 It is an additional object of the invention to provide flexible routing of an inbound 

6 voice call over a particular trunk to one or more lines in a premises. 
7 

8 It is still another object of the invention to provide such flexible routing in 

9 accordance with one or more routing tables and/or caller ID information that is part of the 
1 0 inbound voice call. 

11 

12 In accord with these objects, which will be discussed in detail below, a telephony 

1 3 system for a premises includes lines operably coupled to telephony devices, and trunks 

1 4 operably coupled to diverse networks (such as the PSTN network, one or Internet-based 

1 5 VOIP networks, and a WATS line). The lines may be directly connected to the telephony 

1 6 devices, or coupled thereto via a Public Branch Exchange (PBX) or key telephone system 

1 7 (KTS). A voice router includes a switch matrix operably coupled between the lines and 

1 8 trunks. In processing an outgoing voice call placed on a particular line, switch control 

1 9 means (e.g., a programmed microprocessor) controls the switch matrix to connect the 

20 particular line to at least two trunks (preferably in accordance with at least one routing 

21 table). The switch control means analyzes DTMF digit data (corresponding to DTMF 

22 digit tone(s) generated on the line) to determine a classification tag for the outgoing voice 

23 call, and disconnects (drops) the particular line from at least one trunk (which is 
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1 preferably accomplished prior to completion of dialing) based upon the classification tag 

2 to enable the outgoing voice call to proceed over another one of the at least two trunks. 

3 An incoming voice call received over a particular trunk is connected to one or more lines 

4 by the switch matrix (preferably in accordance with at least one routing table). 
5 

6 It will be appreciated that this architecture does not intercept, store and redial the 

7 dialed number, thereby providing advanced routing functionality with lower costs. 
8 

9 According to one embodiment of the invention, one or more VOIP trunks couple 

1 0 the voice router to an external VOIP gateway. According to another embodiment of the 

1 1 invention, the voice router is integrated with VOIP gateway functionality within a 

1 2 common system housing. In such applications, the voice router may preferentially route 

1 3 local calls (as well as toll-free calls and emergency-91 1 calls) over the PSTN trunks, and 

1 4 preferentially route long distance calls (as well as international calls and site-to-site calls) 

1 5 over the VOIP trunks, to thereby minimize telephone usage costs that are attributable to 

1 6 calls placed over these networks. 
17 

1 8 Optionally, the voice router is adapted to directly connect the telephony devices in 

1 9 there idle state to the PSTN, thereby ensuring that all of the local signaling between the 

20 central office and the premise are preserved. This removes any conformance issues and 

21 greatly increases the reliability of the installation. 
22 
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1 Additional objects and advantages of the invention will become apparent to those 

2 skilled in the art upon reference to the detailed description taken in conjunction with the 

3 provided figures. 
4 

5 BRIEF DESCRIPTION OF THE DRAWINGS 

6 

7 Fig. 1 a simplified block diagram of a network environment that incorporates the 

8 voice routing mechanism in accordance with the present invention; 
9 

1 0 Fig. 2 is a functional block diagram illustrating the system architecture of an 

1 1 exemplary realization of the voice router of Fig. 1 ; 
12 

1 3 Fig. 3A illustrates the logical organization of an Inbound Routing Table utilized 

14 by the voice router of Figs. 1 and 2 in accordance with the present invention. 
15 

1 6 Figs. 3B and 3C illustrate exemplary Inbound Routing Tables for use by the voice 

1 7 router of Figs. 1 and 2 in accordance with the present invention. 
18 

1 9 Fig. 4A illustrates the logical organization of an Outbound Routing Table utilized 

20 by the voice router of Figs. 1 and 2 in accordance with the present invention. 
21 
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1 Figs. 4B, 4C, 4D and 4E illustrate exemplary Local Outbound Routing Tables and 

2 Long Distance Outbound Routing Tables for use by the voice router of Figs. 1 and 2 in 

3 accordance with the present invention. 
4 

5 Fig. 5A illustrates the logical organization of a Trunk Ownership Data Structure 

6 utilized by the voice router of Figs. 1 and 2 in accordance with the present invention. 
7 

8 Fig. 5B illustrates the logical organization of a Line Ownership Data Structure 

9 utilized by the voice router of Figs. 1 and 2 in accordance with the present invention. 
10 

1 1 Fig. 6 is a flow chart describing the high level multi-threaded processing 

1 2 architecture that is part of the microprocessor-based voice routing routine of Fig. 2 in 

1 3 accordance with the present invention. 
14 

1 5 Figs. 7A and 7B, in combination, is a flow chart that details the outgoing call 

1 6 processing operations carried out as part of the microprocessor-based voice routing 

1 7 routine of Fig. 2 in accordance with the present invention. 
18 

1 9 Figs. 8 A and 8B, in combination, is a flow chart that details the incoming call 

20 processing operations carried out as part of the microprocessor-based voice routing 

21 routine of Fig. 2 in accordance with the present invention. 



22 
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1 Fig. 9 is a flow chart that details operations that update the connections of the 

2 switch matrix for idle trunks and lines; these operations are carried out as part of the 

3 microprocessor-based voice routing routine of Fig. 2 in accordance with the present 

4 invention. 
5 

6 Fig. 10 is a flow chart that details operations that monitors the quality of service 

7 (QOS) of the VOIP network and modifies the routing of VOIP calls based thereon; these 

8 operations are carried out as part of the microprocessor-based voice routing routine of 

9 Fig. 2 in accordance with the present invention. 



10 



1 1 Fig. 1 1 is a diagram illustrating the parallel routing operations of the voice router 

1 2 of Figs. 1 and 2 in accordance with the present invention. 
13 

1 4 Fig. 12 is a simplified block diagram of a network environment that incorporates 

15 an alternate voice routing mechanism in accordance with the present invention; 
16 

1 7 Fig. 13 is a functional block diagram illustrating the system architecture of an 

1 8 exemplary realization of the voice router/gateway of Fig. 12; 
19 

20 Fig. 14 is a simplified block diagram of a network environment that incorporates a 

21 PBX and voice routing mechanism in accordance with the present invention; and 



22 
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1 Fig. 15 is a functional block diagram illustrating the system architecture of an 

2 alternate embodiment of a voice routing mechanism in accordance with the present 

3 invention. 
4 

5 DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

6 

7 Turning to Fig. 1, there is shown a simplified block diagram of a network 

8 environment that incorporates the voice routing mechanism in accordance with the 

9 present invention. The environment includes a first premises 10, which may be a home, 

1 0 office building or office space within a larger office building. The premises 10 includes a 

1 1 LAN 12, which is preferably realized by an Ethernet-type switching network supporting a 

1 2 number of wired or wireless communications links, that interconnects a number of locally 

1 3 situated devices, such as one or more networked computers (one shown as 14), one or 

1 4 more networked printers (not shown), etc. The LAN 12 also includes an IP 

1 5 Router/Firewall device 16 and Internet Access Device 18 (e.g., cable modem, xDSL 

1 6 modem, etc) that cooperate to route IP packets between the devices operably coupled to 

1 7 the LAN 12 and the Internet 20. 
18 

1 9 The premises 10 is equipped with a number of analog telephony devices (such as 

20 analog telephones, fax machines or modems) that produce and/or receive analog signals 

21 typically carried over a POTS connection. In the illustrative embodiment shown, there 

22 are two analog telephones shown as 22a and 22b. A PSTN Network Interface Unit (NIU) 

23 24 provides a connection point for one or more trunks (e.g., a copper twisted pair) that 
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1 are operably coupled to the local central office 26 of the public-switched telephone 

2 network (PSTN) 28. The NIU 24, which is typically found on the outside of a residence 

3 in the United States, is the demarcation point between the telephone company's 

4 equipment and the subscriber's equipment. In the exemplary embodiment shown, the 

5 Network Interface Unit 24 provides a connection point to two copper twisted pair, trunk 0 

6 and trunk 1. Traditional POTS-based calls are placed/received over the trunk(s) of the 

7 NIU 24 and PSTN. Such POTS-based calls can include local calls which connect to a 

8 local subscriber's premises equipment (shown as premises 30, NIU, 32 and analog 

9 telephone equipment 34), long distance calls which connect to a remote subscriber's 

1 0 premises equipment (shown as premises 36, NIU 38 and analog telephone 40 coupled to 

1 1 the remote central office 42 of the PSTN 28), toll-free calls, and/or emergency-91 1 calls. 

1 2 Note that a multi-channel Tl trunk may be used to couple the premises 10 to the local 

1 3 central office 26. In this configuration, a Tl channel service unit and channel bank may 

14 be used to provide a plurality of trunks that interface to the analog telephony devices of 

1 5 the premises 10 via the voice router 58. 
16 

1 7 The premises 10 is also equipped with a VOIP gateway 44 operably coupled to 

1 8 the LAN 12. The VOIP gateway 44 provides an interface between one or more analog 

1 9 telephony devices and the Internet-based VOIP network. The VOIP gateway 44 

20 cooperates with the router/firewall 16 and Internet Access Device 18 to place/receive 

21 VOIP calls over the Internet-based VOIP network. Such VOIP calls can include long 

22 distance calls (or international calls or site-to-site) which connect to a remote subscriber's 

23 premises equipment. For example, a VOIP call can connect to subscriber's premises 
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1 equipment at remote premises 46 as shown in Fig. 1 . This equipment includes an IP 

2 phone 48 (connected via a LAN 49 to router/firewall device 50 and Internet Access 

3 Device 52), and an analog telephone 54 (connected via a VOIP gateway 54, LAN 49, 

4 router/firewall device 50 and Internet Access Device 52). The VOIP calls can also 

5 connect through parts of the PSTN. For example, a VOIP call can connect to subscriber's 

6 premises equipment at remote premises 36 through a VOIP gateway 56 (typically 

7 realized by a large-scale VOIP gateway device) operably coupled between the Internet 

8 and the PSTN. In a similar manner, the VOIP calls can connect to the local premises 30. 

9 Typically, it is preferable that such VOIP calls connect through the PSTN at a point near 

1 0 premises 30, 36 in order to minimize the costs associated with routing the call over the 

1 1 PSTN network. 
12 

1 3 With respect to outbound VOIP calls, the VOIP gateway 44 is responsible for IP- 

1 4 based call origination, analog-to-digital conversion of voice signals (and other analog 

1 5 signals) provided by the analog telephony device(s) coupled thereto, the creation of voice 

1 6 packets that represent such voice signals, and the forwarding of such voice packets to the 

1 7 Internet-based VOIP network via the router/firewall 16 and Internet Access Device 18. 

1 8 With respect to inbound VOIP calls, the VOIP gateway 44 is responsible for IP-based 

1 9 call detection, reception of voice packets from the to the Internet-based VOIP network 

20 via the router/firewall 16 and Internet Access Device 18, and digital-to-analog conversion 

21 of the voice signals represented by the packets for supply to the analog telephony 

22 device(s) coupled thereto. In addition, the VOIP gateway 44 may optionally include 

23 additional features, such as voice (analog and/or digital) compression, echo cancellation, 
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1 silence suppression, and statistics gathering and reporting. Typically, each conversation 

2 (call) is a single IP session transported by a Real-time Transport Protocol (RTP) that runs 

3 over User Datagram Protocol (UDP) as is well known in the communication arts. In 

4 addition, signaling that sets up the call is typically provided by one or more protocols, 

5 such as H.323, Session Initiation Protocol (SIP) and/or Media Gateway Control Protocol 

6 (MGCP), which are well known in the communication arts. 
7 

8 In accordance with the present invention, a voice router 58 is provided that 

9 interfaces between the analog telephony devices (e.g., analog telephones 22a, 22b) and 

1 0 the trunk(s) operably connected to the PSTN via the NIU 24 to support the origination 

1 1 and reception of traditional POTS-based calls over such trunk(s). In addition, the voice 

1 2 router 58 interfaces between the telephony devices (e.g., analog telephones 22a, 22b) and 

1 3 the VOIP gateway 44 to support the origination and reception of VOIP calls over the 

14 Internet-based VOIP network. With respect to outbound calls placed from a given analog 

1 5 telephony device, the voice router 58 carries out an improved parallel dialing 

1 6 methodology that is triggered by the detection that the given analog telephony device has 

1 7 gone off-hook. This condition is indicated by the flow of line current that results from 

1 8 the device going off-hook. This line current is supplied to the voice router 58 over a line 

1 9 (e.g., a copper twisted pair) operably coupled between the given analog telephony device 

20 and the voice router 58. As part of the parallel dialing methodology, two or more trunks 

21 (preferably including a PSTN trunk and a VOIP trunk) are seized and one or more DTMF 

22 dial tones (which are generated by the given analog telephone device and supplied to the 

23 voice router 58 over the line therebetween) are simultaneously routed over the two or 
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1 more seized trunks. Note that the DTMF tones are preferably routed over the two or 

2 more seized trunks without storage (and subsequent redialing) of such DTMF tones. 

3 These operations ensure compliance to the local signaling specifications of the central 

4 office, which is difficult to accomplish with a store and redial approach. The dial digit(s) 

5 corresponding to the DTMF tone(s) are analyzed by the voice router 58 (preferably 

6 utilizing a pattern matching operation as described herein) to select a preferred route 

7 classification corresponding thereto. In the preferred embodiment of the present 

8 invention, the preferred route classifications include a first value that indicates that the 

9 call should be preferably routed over the PSTN, and a second value that indicates that 

1 0 that the call should be preferably routed over the Internet-based VOIP network. In order 

1 1 to minimize costs to the subscriber, the first value is typically assigned to local calls (and 

1 2 possibly toll-free calls and emergency-91 1 calls) and the second value is typically 

1 3 assigned to long distance calls (and possibly international and site-to-site calls). In 

1 4 alternate embodiments of the present invention, the preferred route classifications can 

1 5 include values that indicate preferential routing over other networks (such as a WATS 

1 6 line or one of a plurality of Internet-based VOIP networks. After determining the 

1 7 preferred route classification, the unwanted seized trunk(s), which does not correspond to 

1 8 the preferred route classification, is released from the line of the given analog telephony 

1 9 device in order to terminate the dialing operations (and associated call signaling 

20 operations, if any) that occur over the unwanted trunk(s). The connection between the 

21 line of the given analog telephony device and the preferred trunk (that trunk which 

22 corresponds to the preferred route classification) is maintained such that the dialing 
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1 operations (and associated call signaling operations) and subsequent communication (if 

2 the call is successful) occur over the preferred trunk. 
3 

4 The voice router 58 is also preferably configured to connect "idle" lines to 

5 "idle"trunks in accordance with an inbound call routing preferences tables (referred to 

6 herein as the Inbound Routing Table). This feature enables the voice router 58 to provide 

7 miscellaneous idle-time signaling (such as message waiting indications or billing 

8 information) from the "idle" trunks to the "idle" lines. Note that the protocols for such 

9 idle-time signaling vary widely over the PSTN. The automatic connection of "idle" lines 

10 to "idle" trunks provided by the voice router 58 affords an efficient mechanism to support 

1 1 such protocol variations. 
12 

13 In addition, the voice router 58 is preferably configured to operate in case of 

1 4 power failure such that the lines for one or more of the analog telephony devices (e.g., 

1 5 analog telephones 22a, 22b) are electrically connected to the PSTN trunk line(s) via the 

1 6 NIU 24. This enables the analog telephony devices to draw power from the POTS 

1 7 service (i.e., line current) provided by the PSTN trunk to ensure normal operation in the 

1 8 case of power failure. 
19 

20 Advantageously, the parallel routing operations carried out by the voice router 58 

21 do not require local number storage, redial circuitry, and circuitry to determine that the 

22 dial is successful and thus provides a low cost solution. In addition, these operations 

23 ensure compliance to the local signaling specifications of the central office, which is 
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1 difficult to accomplish with local number storage and redial circuitry. In addition, the 

2 omission of such circuitry enables improved fidelity of connection, which can enhance 

3 the speed at which modems, faxes and other analog telephony devices can connect over 

4 the voice router 58. Moreover, these operations are intrinsically more robust and 

5 facilitate pass-through routing in case of power failure whereby the lines for the analog 

6 telephony devices are electrically connected to the PSTN trunk line(s) via the NIU 24. 

7 Additionally, if the voice router 58 is used in a facility in which the speed at which calls 

8 can be placed is important (such as an outbound call center), these operations provide for 

9 minimal delay in placing the outbound call while maintaining the cost advantages of 
1 0 selective call routing over the PSTN and Internet-based VOIP network. 

11 

1 2 Fig. 2 is a functional block diagram illustrating the system architecture of an 

1 3 exemplary realization of the voice router 58 of Fig. 1. The voice router 58 includes four 

14 line ports (102a, 102b, 102c and 102d) that connect to corresponding lines (line 0, line 1, 

1 5 line 2 and line 3) that lead to the analog telephony devices (e.g., analog telephone 22a, 

1 6 analog telephone 22b, etc) of the premises 10. The voice router 58 also includes two 

17 PSTN trunk ports (104a, 104b) that connect to corresponding trunks (trunk 0, trunk 1) 

1 8 that lead to the NIU 24 of the premises 10, and two VOIP trunk ports (106a, 106b) that 

1 9 connect to corresponding trunks (trunk 2, trunk 3) that lead to VOIP gateway 44. 

20 Preferably, the ports 102a, 102b, 102c, 102d, 104a, 104b, 106a, 106b are realized by RJ- 

21 1 1 ports and the lines/trunks are realized by copper twisted pairs. A switch matrix 108 

22 provides a switchable connection between one or more of the line ports (ports 102a - 

23 102d) and one or more of the trunk ports (104a, 104b, 106a, 106b) under control of 
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1 switch control logic 1 10. The four line ports 102a -102d are coupled to line interface 

2 circuitry 1 12 which provides off-hook detection for the analog telephony devices coupled 

3 thereto in addition to detection of DTMF digits dialed by the analog telephony devices 

4 coupled thereto. Preferably, such off-hook detection is provided by an opt-coupler and 

5 digital filtering (which may be realized by a field programmable logic device, other 

6 programmable logic device, an ASIC, or other integrated circuit). In addition, the DTMF 

7 detection is preferably realized by an integrated circuit such as the DTMF Receiver 

8 75T204 commercially available from TDK Semiconductor of Tustin, CA. The four trunk 

9 ports 104a, 104b, 106a, 106b are coupled to trunk interface circuitry 1 14 which provides 

1 0 ring detection (e.g., detecting the ring voltage supplied over the trunk lines 0 - 4), and 

1 1 preferably Caller ID detection (which typically involves demodulating and decoding an 

1 2 FSK signal that occurs immediately after the first ring burst). Preferably, such ring 

1 3 detection and caller ID detection is provided by an integrated circuit, such as the 

1 4 MT88E43B commercially available from Zarlink Semiconductor of Ottowa, Canada. 
15 

1 6 Note that the local central office 26 (via the NIU 24) and the VOIP gateway 44 

1 7 provide a Foreign Exchange Station (FXS) interface that delivers POTS service 

1 8 (including line current, ring voltage, dial tone) over the trunks 0 - 4 to the analog 

1 9 telephony devices coupled thereto via the switch matrix 108. The FXS interface also 

20 performs off-hook detection (i.e., detection of line current indicating that the trunk has 

21 been seized). In addition, the analog telephony devices (e.g., analog telephones 22a, 22b) 

22 include a Foreign Exchange Office (FXO) interface that receives POTS service (e.g., line 
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1 current, ring voltage, dial tone) from the trunks 0 - 4 coupled thereto via the switch 

2 matrix 108. 
3 

4 In this configuration, an inbound PSTN call triggers the FXS interface of the local 

5 Central Office 26 to initiate a call by presenting a ring voltage over the PSTN trunk 

6 (trunk 0 or trunk 1). The switch matrix 108, which is configured to connect the PSTN 

7 trunk to one or more lines, passes the ring voltage over these line(s) to the attached 

8 analog telephony device(s). The FXO interface of the attached analog telephony 

9 device(s) detects the ring voltage (which triggers the phone to ring). When the telephone 

1 0 goes off-hook (i.e., "activated/picked up" by the user), line current flows through the loop 

1 1 coupled to the analog telephony device(s). This line current is detected by the FXS 

1 2 interface of the local Central Office 26. Similarly, an inbound VOIP call triggers the 

1 3 FXS interface of the VOIP gateway 44 to initiate a call by presenting a ring voltage over 

1 4 the VOIP trunk (trunk 2 or trunk 3). The switch matrix 108, which is configured to 

1 5 connect the VOIP trunk to one or more lines, passes the ring voltage over these line(s) to 

1 6 the attached analog telephony device(s). The FXO interface of the attached analog 

1 7 telephony device(s) detects the ring voltage (which triggers the phone to ring). When the 

1 8 telephone goes off-hook (i.e., "activated/picked up" by the user), line current flows 

1 9 through the loop coupled to the analog telephony device(s). This line current is detected 

20 by the FXS interface of the VOIP gateway 44. 
21 

22 Preferably, the switch matrix 108 is configured to operate in case of power failure 

23 such that the lines for one or more of the analog telephony devices (e.g., analog 
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telephones 22a, 22b) are electrically connected to the PSTN trunk line(s) via the NIU 24. 
This feature can be realized by using normally-open relays for the interconnection means 
of the switch matrix 108 except on the diagonal where normally closed relays are 
employed. This arrangement ensures that in the absence of power, every trunk will be 
connected to its corresponding line. This feature enables the analog telephony devices to 
draw power from the line current provided by the PSTN trunk lines to ensure normal 
operation of these devices in the case of power failure. 

The microprocessor system 116 includes a voice routing control routine 118 
that carries out a parallel dialing methodology in accordance with the present invention. 
Note that the switch matrix 108 is configured in its idle state to connect idle line(s) to 
corresponding idle trunk(s) such that inbound/outbound calls can be placed and received 
over these connections. An outbound call is initiated when a given analog telephone 
device goes off-hook (i.e., "activated/picked up" by the user) and line current flows 
through the loop coupled to the given analog telephony device. This local loop can be 
terminated at the local Central Office 26 in the event that the "idle state" configuration 
connects the line for the given analog telephone device to a PSTN trunk. Alternatively, 
this local loop can be terminated at the VOIP Gateway 44 in the event that the "idle state" 
configuration connects the line for the given analog telephone device to a VOIP trunk. In 
either case, the line interface circuitry 1 12 of the voice router 58 detects this line current 
and provides an off-hook detect control signal to the microprocessor system 1 16 in 
response thereto. The routine 1 18 is triggered by this off-hook detect control signal. As 
part of the parallel dialing methodology, the routine 1 18 identifies two or more idle 
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1 trunks, and seizes these two or more idle trunk(s) by controlling the switch control 1 10 to 

2 adjust the switch matrix 108 to connect the line port for the given analog telephone 

3 device to the trunks ports corresponding to these two or more idle trunk(s). Line current 

4 flows through these idle trunk(s) for detection by the FXS interface that terminates such 

5 trunk(s). In this manner, multiple trunks are connected to the line for the given analog 

6 telephony device and seized by the device. Preferably, these multiple trunks include a 

7 PSTN trunk and a VOIP trunk as will be described hereinafter. 
8 

9 Subsequent thereto, the FXO interface of the given analog telephone device dials 

1 0 the DTMF digits, which identify the destination to be called. One or more of these 

1 1 DTMF digits are simultaneously routed to the multiple trunks connected thereto by the 

1 2 switch matrix 108. In the event that a PSTN trunk is coupled to the given analog 

1 3 telephone device by the switch matrix 108, the FXS interface of the local Central Office 

1 4 26 that terminates the PSTN trunk receives these DTMF digits. Based upon these DTMF 

1 5 digits, the local Central Office 26 performs signaling operations that sets up the voice 

1 6 circuit path through the PSTN for the call, and routes the call over the voice circuit path. 

1 7 Similarly, in the event that a VOIP trunk is coupled to the given analog telephone device 

18 by the switch matrix 108, the FXS interface of the VOIP gateway 44 that terminates the 

1 9 VOIP trunk receives these DTMF digits. Based upon these DTMF digits, the VOIP 

20 gateway 44 performs signaling operations that sets up the route through the Internet- 

21 based VOIP network, and routes the call over this path. 
22 
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1 As the DTMF dial digit(s) pass through the voice router 108, the line interface 

2 circuitry 1 12 detects the DTMF dial digit(s) and supplies signals representing the DTMF 

3 dial digits to the routine 1 18. The routine 1 18 utilizes a pattern matching operation that 

4 analyzes the DTMF dial digit(s) and selects a preferred route classification that 

5 corresponds to the DTMF dial digits. The preferred route classifications preferably 

6 include a first value that indicates that the call should be preferably routed over the PSTN 

7 in addition to a second value that indicates that that the call should be preferably routed 

8 over the Internet-based VOIP network. In order to minimize costs to the subscriber, the 

9 first value is typically assigned to local calls (and possibly toll-free calls and emergency- 

10 911 calls) and the second value is typically assigned to long distance calls (and possibly 

1 1 international calls and site-to-site calls). After determining the preferred route 

1 2 classification, the routine 118 releases the unwanted trunk(s) (trunk(s) which do not 

1 3 correspond to the preferred route classification) by controlling the switch control 1 10 to 

1 4 adjust the switch matrix to decouple the trunk port for the unwanted trunk(s) from the 

1 5 line port of the given analog telephony device, thereby terminating the dialing operations 

1 6 (and associated call signaling operations, if any) that occur over the unwanted trunk(s). 

1 7 The routine 118 maintains the connection between the line port of the given analog 

1 8 telephony device and the trunk port for the preferred trunk (that trunk which corresponds 

1 9 to the preferred route classification) such that the dialing operations (and associated call 

20 signaling operations) and subsequent conversation (if the call is successful) occur over 

21 the preferred trunk. After the release of the unwanted trunk(s), the routine 1 18 preferably 

22 updates the idle connections of the switch matrix 108 in accordance with the preferences 

23 of a routing table as is discussed in detail below. 
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1 

2 The microprocessor system 1 16 also maintains a call log 120 that stores 

3 information (such as origination number, destination number, start time, duration, and/or 

4 call type (e.g., PSTN or VOIP)) related to the inbound and/or outbound calls that are 

5 routed through the voice router 58. Such information is collected by the microprocessor 

6 system 1 16 as the calls are originated, received and terminated. Preferably, the call log is 

7 accessible to users over an Ethernet link to the LAN 12 as provided by an Ethernet 

8 interface 122. For example, access to the call log 120 can be provided by a network- 

9 based utility executing on the client machine 14 operably coupled to the LAN 12. 

1 0 Alternatively, the microprocessor system 1 16 can include an embedded web server that 

1 1 serves up the call log such that it can be accessed by users executing a standard web 

1 2 browser on the client machine 14. 
13 

1 4 The microprocessor system 1 16 also provides a configuration routine 124 that 

1 5 enables users to configure operational parameters (e.g., network parameters, routing 

1 6 tables, QOS parameters, feature enablement/disablement, etc). Preferably, the 

1 7 configuration routine is accessible to users over an Ethernet link to the LAN 12 as 

1 8 provided by the Ethernet interface 122. For example, access to the configuration routine 

19 124 can be provided by a network-based utility executing on the client machine 14. 

20 Alternatively, the microprocessor system 1 16 can include an embedded web server that 

21 enables web-based configuration of the operational parameters by users executing a 

22 standard web browser on the client machine 14. 
23 
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1 Turning now to Figs. 3A - 5B, there is shown exemplary data structures that may 

2 be used by the microprocessor-based voice routing routine 1 18 of the voice router 58 to 

3 realize the parallel routing methodology in accordance with the present invention. These 

4 data structures include an Inbound Routing Table, an Outbound Routing Table pertaining 

5 to each route classification (e.g., local and long distance), a Trunk Ownership byte 

6 pertaining to each trunk, and a Line Ownership byte pertaining to each line. 
7 

8 As shown in Fig. 3A, the Inbound Routing Table is logically organized as an 

9 array of rows and columns. Each row uniquely corresponds to one of the trunk ports of 

1 0 the voice router 58. The columns provide an ordered list of line assignments wherein the 

1 1 first column is most preferred and the last column is least preferred. The cells of the 

1 2 column include line ID values (or Groups of one or more Line ID values) that identify the 

1 3 lines that are assigned to the trunk ports corresponding to the rows of the cells. Note that 

14 in the case that the cells include Groups of Line ID values, each line of the Group may be 

1 5 connected to the assigned trunk port such that the lines of the group ring concurrently. 

1 6 Also note that each cell may include an ordered list of groups (from "most preferred" to 

1 7 least preferred). In this case, during incoming call processing on a particular trunk, if any 

1 8 line of the "most preferred" group is unavailable, the processing continues on to the next 

1 9 group. Upon detecting the first "available" group, each line of the Group is preferably 

20 connected to the assigned trunk port such that the lines of the group ring concurrently. 

21 Alternatively, the Line ID values over the second to last columns of the Inbound Routing 

22 Table can include a PCON (parallel connect) bit. When set, the Line corresponding to 

23 the Line ID (if available) is connected in parallel to the ringing inbound trunk. In this 
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1 case, the search over the row of the table is concluded when an entry is found with out 

2 the PCON bit set. 
3 

4 Fig. 3B illustrates a first exemplary Inbound Routing Table. For the "most 

5 preferred line assignment" (column 1), line 0 is assigned to PSTN trunk 0, line 1 is 

6 assigned to PSTN trunk 1 , line 2 is assigned to VOIP trunk 2, and line 3 is assigned to 

7 VOIP trunk 3. For the "least preferred trunk assignment" (column 4), line 3 is assigned 

8 to PSTN trunk 0, line 3 is assigned to PSTN trunk 1, line 0 is assigned to VOIP trunk 2, 

9 and line 0 is assigned to VOIP trunk 3. 
10 

1 1 Fig- 3C illustrates a second exemplary Inbound Routing Table. For the "most 

1 2 preferred line assignment" (column 1 ), line 0 is assigned to PSTN trunk 0, the group (line 

1 3 0, line 1) is assigned to PSTN trunk 1, the ordered list of groups (line 0, line 1) and (line 

14 1 , line 2) is assigned to VOIP trunk 2, and line 3 is assigned to VOIP trunk 3. For the 

1 5 "least preferred trunk assignment" (column 4), line 3 is assigned to PSTN trunk 0, no 

1 6 trunk (FF) is assigned to PSTN trunk 1, no trunk (FF) is assigned to VOIP trunk 2, and 

1 7 line 0 is assigned to VOIP trunk 3. In processing an incoming call on PSTN trunk 1, it is 

1 8 preferred that the group (line 0, line 1) be connected to the trunk port for PSTN trunk 1 

1 9 such that line 0 and line 1 ring concurrently. Similarly, in processing an incoming call on 

20 PSTN trunk 1 , it is preferred that the group (line 0, line 1) be connected to the trunk port 

21 for PSTN trunk 1 such that line 0 and line 1 ring concurrently; however, if line 0 or line 1 

22 is unavailable, it is preferred that the group (line 1, line 2) be connected to the trunk port 

23 for PSTN trunk 1 such that line 1 and line 2 ring concurrently. 
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1 

2 As shown in Fig. 4A, the Outbound Routing Table is logically organized as an 

3 array of rows and columns. Each row uniquely corresponds to one of the line ports of the 

4 voice router 58. The columns provide an ordered list of trunk assignments wherein the 

5 first column is most preferred and the last column is least preferred, and the cells of the 

6 column include trunk ID values that identify the trunk that are assigned to the line ports 

7 corresponding to the rows of the cells. Figs. 4B through 4D illustrate exemplary 

8 Outbound Routing Tables. There are preferably different types of routing tables for the 

9 different network types of the system. In the example shown, there are two types of 

1 0 Outbound Routing Tables, one for "local calls" and another for "long distance calls". In 

1 1 the exemplary "Local" Outbound Routing Table of Fig. 4B, for the "most preferred trunk 

1 2 assignment" (column 1), PSTN trunk 1 is assigned to lines 0 - 4. For the "least preferred 

1 3 trunk assignment" (column 4), VOIP trunk 3 is assigned to lines 0 - 4. This configuration 

1 4 biases the routing of outbound "local calls" to the PSTN trunk 1 as will become evident 

1 5 from the description below. In the exemplary "Long Distance" Outbound Routing Table 

1 6 of Fig. 4C, for the "most preferred trunk assignment" (column 1), VOIP trunk 2 is 

1 7 assigned to lines 0 - 4. For the "least preferred trunk assignment" (column 4), PSTN 

1 8 trunk 0 is assigned to lines 0 - 4. This biases the routing of outbound "long distance" 

1 9 calls to the VOIP trunk 2 as will become evident from the description below. 
20 

21 Note that the Outbound Routing Tables may be used to carry information that 

22 inhibits the routing of outbound calls over one or more trunks. For example, the "least 

23 preferred trunk assignment" (column 4) in the exemplary "Local" Outbound Routing 
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1 Table of Fig. 4D utilizes a value FF to indicate no trunk is assigned to lines 0 - 4. This 

2 will inhibit the routing of outbound local calls over the VOIP trunks 2 and 3 in the event 

3 that the routing preferences in columns 1 and 2 cannot be satisfied (i.e., PSTN trunks 0 

4 and 1 are busy servicing other calls). In another example, the "least preferred trunk 

5 assignment" (column 4) in the exemplary "Long Distance" Outbound Routing Table of 

6 Fig. 4E utilizes a value FF to indicate no trunk is assigned to lines 0 - 4. This will inhibit 

7 the routing of outbound long distance calls over the PSTN trunks 0 and 1 in the event that 

8 the routing preferences in columns 1 and 2 cannot be satisfied (i.e., VOIP trunks 3 and 2 

9 are busy servicing other calls). 
10 

1 1 As shown in Fig. 5 A, the Trunk Ownership byte pertaining to a given trunk 

1 2 includes an active status field (bit 7), an optimization status field (bit 6), and data bits 5-0. 

1 3 Thus there are four separate and distinct ownership bytes pertaining to the four trunks 0 - 

14 4. In each Trunk Ownership byte, the active status field, when set to 'active'/ 4 1\ 

1 5 indicates the given trunk is active (e.g., it is currently being used by an incoming or 

1 6 outgoing call). Conversely, the active status field, when set to 'inactiveV'O', indicates the 

1 7 given trunk is inactive (e.g., it is not currently being used by an incoming or outgoing 

1 8 call). The optimization status field, when set to 'OPT 1', indicates the assignment of the 

1 9 given trunk is currently being optimized in conjunction with the matrix update operations 

20 described below with respect to Fig. 9. Conversely, the optimization status field, when 

21 set to 'NOPV'O', indicates the assignment of the given trunk is not currently being 

22 optimized in conjunction with the matrix update operations described below with respect 

23 to Fig. 9. If the given trunk is "active", bits 5-0 contain a call object identifier for the 
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1 call object that owns the trunk. If the given trunk is "inactive", bits 5-0 contain a default 

2 trunk identifier (0 for the trunk ownership byte pertaining to trunk 0, 1 for the trunk 

3 ownership byte pertaining to trunk 1, 2 for the Trunk Ownership byte pertaining to trunk 

4 2, and 3 for the trunk ownership byte pertaining to trunk 3). 
5 

6 As shown in Fig. 5B, the Line Ownership byte pertaining to a given line includes 

7 an active status field (bit 7), an optimization status field (bit 6), and data bits 5-0. Thus 

8 there are four separate and distinct ownership bytes pertaining to the four lines 0-3. In 

9 each Line Ownership byte, the active status field, when set to 'active'/' 1\ indicates the 

1 0 given line is active (e.g., it is currently being used by an incoming or outgoing call). 

1 1 Conversely, the active status field, when set to 'inactiveV'O', indicates the given line is 

1 2 inactive (e.g., it is not currently being used by an incoming or outgoing call). The 

1 3 optimization status field, when set to 'OPV 1 \ indicates the assignment of the given line 

1 4 is currently being optimized. Conversely, the optimization status field, when set to 

1 5 'NOPV'0', indicates the assignment of the given line is not currently being optimized. If 

1 6 the given line is "active", bits 5-0 contain a call object identifier for the call object that 

1 7 owns the line. If the given line is "inactive" and its assignment is currently not being 

1 8 optimized (bit 6 is 'NOP'), bits 5-0 contain a "system" ownership assignment which is 

1 9 determined in conjunction with the matrix update operations described below with 

20 respect to Fig. 9. This ownership is used by the matrix scanning operations to make the 

21 matrix switch connections that best fit the preferences of the Inbound Routing Table. 
22 
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1 Turning now to Figs. 6 through 10, there is shown flow charts illustrating an 

2 exemplary embodiment of operations carried out as part of the microprocessor-based 

3 voice routing routine 1 18. These operations utilize the data structures described above 

4 with respect to Figs. 3A - 5B to realize a parallel routing methodology in accordance with 

5 the present invention. These data structures include an Inbound Routing Table, an 

6 Outbound Routing Table pertaining to each route classification (e.g., local and long 

7 distance), a Trunk Ownership byte pertaining to each trunk, and a Line Ownership byte 

8 pertaining to each line. 
9 

1 0 Fig. 6 describes the high level multi-threaded processing architecture that is part 

1 1 of the microprocessor-based voice routing routine 118. It includes an initialization block 

1 2 601 wherein the data structures (Inbound Routing Table, Outbound Routing Table 

1 3 pertaining to each route classification (e.g., local and long distance), Trunk Ownership 

1 4 byte pertaining to each trunk, and Line Ownership byte pertaining to each line)) are 

1 5 initialized. Preferably, the data structures are modified in accordance with the network- 

1 6 based configuration 124 executed by the microprocessor system 1 16 as set forth above, 

17 and stored in persistence storage (such as a flash memory module). During power 

1 8 up/system reset, the data structures are initialized by loading the stored data structures 

1 9 from persistence storage into allocated portions of the system memory of the 

20 microprocessor system 1 16. The high level processing also invokes a system thread that 

21 provides for allocation of system resources and event handling (block 603), a thread that 

22 performs call processing (block 605), , a thread that updates the switch matrix (block 

23 607), and a thread that monitors the quality of service (QOS) of the Internet-based VOIP 
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network and modifies the Outbound Routing Tables accordingly (block 609), and other 
threads that perform various system level functions (initialization of the hardware 
platform and an IP stack for IP packet processing) and that perform various application 
level functions (configuration, communication of caller-ID information to a user, Call 
Log access, Web Server, etc) (block 611). 

Figs. 7A and 7B provide details of outgoing call processing operations carried out 
in block 605 of Fig. 6. The operations begin in block 701 whereby an outbound call 
object OCOi that is associated with a particular line is spawned in response to an off-hook 
detect control signal provided by interface circuitry 1 12. The outbound call object OCOi 
is tasked to handle an outbound call. It is the recipient of various events (e.g., hook 
signal, DTMF digit data, etc.) and follows a state machine to route, monitor and log the 
call as set forth in blocks 703 to 725. 

In block 703, the "Local" Outbound Call Routing Table and Trunk Ownership 
bytes for the four trunks are accessed to identify a first inactive trunk (bit 7 is set to '0') 
in accordance with the preferences of the "Local" Outbound Call Routing Table. 
Preferably, these operations involve sequencing through the cells of the row of the 
"Local" Outbound Call Routing Table that corresponds to the particular line. The cells 
are accessed from most preferred to least preferred. If the trunk identified by the cell is 
inactive (bit 7 is set to '0'), the trunk ID of the cell is used to identify the first inactive 
trunk. Note that a trunk ID of 'FF' indicates that no trunk is available for "local" routing. 
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1 In block 705, the "Long Distance" Outbound Call Routing Table and Trunk 

2 Ownership bytes for the four trunks are accessed to identify a second inactive trunk (bit 7 

3 is set to '0') in accordance with the preferences of the "Long Distance" Outbound Call 

4 Routing Table. Preferably, these operations involve sequencing through the cells of the 

5 row of the "Long Distance" Outbound Call Routing Table that corresponds to the 

6 particular line. The cells are accessed from most preferred to least preferred. If the trunk 

7 identified by the cell is inactive (bit 7 is set to '0'), the trunk ID of the cell is used to 

8 identify the second inactive trunk. Note that a trunk ID of 'FF' indicates that no trunk is 

9 available for "long distance" routing. 
10 

11 In block 707, the Line Ownership byte pertaining to the particular line is modified 

1 2 such that the outbound call object OCOi claims ownership of the line. This is 

1 3 accomplished by setting the Active Status field (bit 7) to 'active', the Optimization Status 

1 4 field (bit 6) to 'NOP' , and bits 5-0 to the call object identifier for the outbound call object 

15 OCOi. 
16 

17 In block 709, the Trunk Ownership byte pertaining to the first and second inactive 

1 8 trunks identified in blocks 705 and 707 are modified such that the outbound call object 

1 9 OCOi claims ownership of these two trunks. For the Trunk Ownership byte pertaining to 

20 the first inactive trunk, this is accomplished by setting the Active Status field (bit 7) to 

21 'active', the Optimization Status field (bit 6) to 'NOP', and bits 5-0 to the call object 

22 identifier for the outbound call object OCOi. Similar operations are performed with 

23 respect to the Trunk Ownership byte pertaining to the second inactive trunk. Note that 
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1 the switch matrix update operations of block 607 periodically scan (for example, every 30 

2 ms) the Line Ownership bytes and Trunk Ownership bytes to ascertain whether the bits 5- 

3 0 match (and the optimization status field is 'NOP'). If so, switch matrix update 

4 operations cooperate with switch control 1 10 to update the switch matrix to connect the 

5 matching trunk and line. In this manner, the scan of the Line Ownership bytes and Trunk 

6 Ownership bytes that occurs subsequent to blocks 707 and 709 will control the switch 

7 matrix to connect the particular line to the first and second trunks owned by the outbound 

8 call object OCOi. When the switch matrix connects the particular line to the first and 

9 second trunks owned by the outbound call object OCOi, line current flows through these 
1 0 two trunks such that they are seized by the telephone device. 

11 

1 2 Note that in the event that there is no trunk available for "local" routing (i.e., the 

1 3 ID for the first inactive trunk in block 705 is FF), the modification of the Trunk 

1 4 Ownership byte for the first inactive trunk is omitted. In this case, the subsequent scan of 

1 5 the Line Ownership bytes and Trunk Ownership bytes will not control the switch matrix 

16 to connect the particular line to a 'local' trunk. Similarly, in the event that there is no 

1 7 trunk available for "long distance" routing (i.e., the ID for the second inactive trunk in 

1 8 block 707 is FF), the modification of the Trunk Ownership byte for the second inactive 

1 9 trunk is omitted. In this case, the subsequent scan of the Line Ownership bytes and Trunk 

20 Ownership bytes will not control the switch matrix to connect the particular line to a 

21 'longdistance' trunk. 
22 
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1 In block 711, DTMF digits (which are detected by the line interface circuitry 1 12 

2 signals in response to DTMF digit tones generated by the FXO interface of the analog 

3 telephone device on the particular line) are monitored and processed to determine 

4 whether the call is classified as a "local" call or a "long distance" call. Preferably, such 

5 operations utilize pattern matching operations with respect to the DTMF digits as they are 

6 generated to identify the correct classification of the call. In block 713, it is determined 

7 whether the class classification is long distance (or local). 
8 

9 If the classification is "long distance" in block 713, the operations continue to 

1 0 block 7 15 to modify the Trunk Ownership byte for the particular trunk such that 

1 1 outbound call object OCOj releases ownership of the first trunk - that trunk identified in 

12 block 703. This is accomplished by setting the Active Status field (bit 7) to 'inactive', 

1 3 the Optimization Status field (bit 6) to 'NOP', and bits 5-0 to the default trunk identifier. 

14 In this manner, the scan of the Line Ownership bytes and Trunk Ownership bytes that 

1 5 occurs subsequent to block 715 will control the switch matrix to disconnect the particular 

1 6 line from the unwanted first trunk, thereby terminating the dialing operations (and 

1 7 associated call signaling operations, if any) that occur over the unwanted trunk. The 

1 8 operations of block 715 maintains the connection between the particular line and the 

1 9 preferred "long distance" trunk identified in block 705 such that the dialing operations 

20 (and associated call signaling operations) and subsequent conversation (if the call is 

21 successful) occur over the preferred trunk. 
22 
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1 If the classification is "local" in block 713, the operations continue to block 717 

2 to modify the Trunk Ownership byte for the particular trunk such that outbound call 

3 object OCOj releases ownership of the second trunk - that trunk identified in block 705. 

4 This is accomplished by setting the Active Status field (bit 7) to 'inactive', the 

5 Optimization Status field (bit 6) to 'NOP', and bits 5-0 to the default trunk identifier. In 

6 this manner, the scan of the Line Ownership bytes and Trunk Ownership bytes that 

7 occurs subsequent to block 717 will control the switch matrix to disconnect the particular 

8 line from the unwanted second trunk, thereby terminating the dialing operations (and 

9 associated call signaling operations, if any) that occur over the unwanted trunk. The 

1 0 operations of block 717 maintain the connection between the particular line and the 

1 1 preferred "local" trunk identified in block 703 such that the dialing operations (and 

1 2 associated call signaling operations) and subsequent conversation (if the call is 

1 3 successful) occur over the preferred trunk. 
14 

1 5 After blocks 7 1 5 and 7 1 7, the operations continue to blocks 7 1 9 whereby 

1 6 information regarding the call (such as destination number and start time) are added to 

1 7 the call log 120. In addition, the connections of the switch matrix are updated to best 

1 8 meet the preferences of the Inbound Routing Table. These switch matrix update 

1 9 operations are set forth in detail in Fig. 9 and in the corresponding description below. 
20 

21 In block 721, the operations wait unit the call has been terminated and then 

22 continue to block 723 to modify the Trunk/Line Ownership bytes such that the outbound 

23 call object OCOj releases ownership for the line/trunk seized for the call. This is 
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1 accomplished by setting the Active Status field (bit 7) to inactive', the Optimization 

2 Status field (bit 6) to 'NOP', and bits 5-0 to the default trunk identifier. In this manner, 

3 the scan of the Line Ownership bytes and Trunk Ownership bytes that occurs subsequent 

4 to block 717 will control the switch matrix to disconnect the particular line from the trunk 

5 used for the call. 
6 

7 After block 723, the operations continue to block 725 whereby information 

8 regarding the call (such as end time and/or call duration) is added to the call log 120. In 

9 addition, the connections of the switch matrix are updated to best meet the preferences of 

1 0 the Inbound Routing Table. These switch matrix optimization operations are set forth in 

1 1 detail in Fig. 9 and in the corresponding description below. The call processing 

1 2 operations for the given call then end, and are typically repeated for subsequent outbound 

1 3 calls placed over the lines coupled to the voice router 58. 
14 

1 5 Figs. 8A and 8B provide details of incoming call processing operations carried 

1 6 out in block 605 of Fig. 6. The operations begin in block 801 whereby an inbound call 

1 7 object ICO x that is associated with a particular trunk is spawned in response to a ring 

18 detection control signal provided by the trunk interface circuitry 1 14. The inbound call 

1 9 object ICO x is tasked to handle an inbound call and is the recipient of various events 

20 (e.g., ring detect signal, CID data etc.) and follows a state machine to route, monitor and 

21 log the call as set forth in blocks 803 to 817. 
22 



-33- 



NETF-002 

1 In block 803, Caller ID information (which is provided by the trunk interface 

2 circuitry 1 14) and the Line Ownership bytes are used to access a Caller ID Routing Table 

3 and identify an inactive line (bit 7 is set to '0) in accordance with the preferences of the 

4 Caller ID Routing Table. The Caller ID Routing Table is similar in nature to the Inbound 

5 Call Routing Table yet assigns a preferred line (or group(s) of lines) to calls from a 

6 particular Caller ID. Preferably, these operations involve sequencing through the cell(s) 

7 of the row of the Caller ID Routing Table that corresponds to the particular caller ID. 

8 The cells are accessed from most preferred to least preferred. If the line(s) identified by 

9 the cell is inactive (bit 7 is set to 4 0'), the line ID(s) of the cell is used to identify the 

1 0 inactive line(s). If the Caller ID route processing fails (or is omitted), the operations of 

1 1 block 803 may utilize the Line Ownership Data Structures and Inbound Call Routing 

1 2 Table to identify an inactive line (or group of lines) (bit 7 is set to '0) in accordance with 

1 3 the preferences of the Inbound Call Routing Table. Preferably, these operations involve 

1 4 sequencing through the cell(s) of the row of the Inbound Call Routing Table that 

1 5 corresponds to the particular trunk. The cells are accessed from most preferred to least 

1 6 preferred. If the line(s) identified by the cell is inactive (bit 7 is set to '0'), the line ID(s) 

17 of the cell is used to identify the inactive line(s). 
18 

1 9 Note that in the preferred embodiment of the present invention, the idle state of 

20 the switch matrix is updated to best meet the preferences of the Inbound Routing Table. 

21 In this configuration, the inbound call will automatically ring on the telephone device 

22 connected to the "idle state" line. Thus, if the Caller ID route processing identifies the 
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1 same "idle state" line, the reconfiguration of the switch matrix in blocks 805 and 809 can 

2 be omitted. 
3 

4 In block 805, the Trunk Ownership byte pertaining to the particular trunk is 

5 modified such that the inbound call object ICO x claims ownership of the trunk. This is 

6 accomplished by setting the Active Status field (bit 7) to 'active', the Optimization Status 

7 field (bit 6) to 'NOP', and bits 5-0 to the call object identifier for the inbound call object 

8 ICO x . 
9 

1 0 In block 807, the Line Ownership byte pertaining to the inactive line(s) identified 

1 1 in block 803 is modified such that the inbound call object ICO x claims ownership of such 

1 2 line(s). This is accomplished by setting the Active Status field (bit 7) to 'active', the 

1 3 Optimization Status field (bit 6) to 'NOP', and bits 5-0 to the call object identifier for the 

1 4 inbound call object ICO x . In this manner, the scan of the Line Ownership Bytes and 

1 5 Trunk Ownership Bytes that occurs subsequent to blocks 805 and 807 will control the 

1 6 switch matrix to connect the particular trunk to the line(s) owned by the inbound call 

1 7 object ICO x . When the switch matrix connects the particular trunk to the line(s) owned 

1 8 by the inbound call object ICO x , line current flows through these line(s) such that the 

1 9 line(s) and particular trunk are seized by the telephone device. 
20 

21 
22 
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1 In block 809, the operations may connect answering machine functionality to the 

2 particular trunk in parallel with the connection to the line(s) owned by the inbound call 

3 object. This may be accomplished by connecting an answering machine device to one of 

4 the lines (e.g., line 4) and configuring the Inbound Routing Table to connect the 

5 answering machine line (line 4) to the inbound trunk in parallel to the connection of the 

6 inbound trunk to one or more analog telephone lines (e.g., lines 1 and 2). Alternatively, 

7 answering machine functionality can be integrated into the routing device 58 itself. In 

8 this case, the voice messages stored therein may be stored in digital form and made 

9 accessible to the user(s) via dialing predetermined DTMF digits over one of the lines (and 
1 0 possibly made accessible over the LAN 12). 

11 

12 In block 811, information regarding the call (such as origination number and start 

1 3 time) is added to the call log 120. In addition, the connections of the switch matrix are 

1 4 updated to best meet the preferences of the Inbound Routing Table. These switch matrix 

1 5 update operations are set forth in detail in Fig. 9 and in the corresponding description 

1 6 below. In addition, the processing may communicate the caller ID information, if any, to 

1 7 a user over the LAN 12. This may be accomplished by a web-based utility, executing on 

18 a client machine, that receives events from the voice router 58 over the LAN (preferably 

1 9 using UDP or TCP). The caller ID information is communicated as an event from the 

20 voice router (preferably using an IP multicast packet containing the detail of the caller ID 

21 information). Alternatively, a web-based utility (for example, a JAVA applet) polls the 

22 voice router 58 periodically and expects a short return (i.e. new data/ no new data). If 
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1 there is new data, then the utility performs an HTTP GET to retrieve the Caller ID 

2 information the voice router 58. 
3 

4 In block 813, the operations wait until the call has been terminated and then 

5 continue to block 815 to modify the Trunk/Line Ownership bytes such that the inbound 

6 call object ICO x releases ownership for the line/trunk seized for the call. This is 

7 accomplished by setting the Active Status field (bit 7) to 'inactive', the Optimization 

8 Status field (bit 6) to 'NOP', and bits 5-0 to the default trunk identifier. In this manner, 

9 the scan of the Line Ownership bytes and Trunk Ownership bytes that occurs subsequent 

10 to block 813 will control the switch matrix to disconnect the particular trunk from the line 

1 1 used for the call. 
12 

1 3 After block 815, the operations continue to block 817 whereby information 

1 4 regarding the call (such as end time and/or call duration) is added to the call log 120. In 

1 5 addition, the connections of the switch matrix are updated to best meet the preferences of 

1 6 the Inbound Routing Table. These switch matrix update operations are set forth in detail 

1 7 in Fig. 9 and in the corresponding description below. The call processing operations for 

1 8 the given call then end, and are typically repeated for subsequent inbound calls placed 

1 9 over the trunks coupled to the voice router 58. 
20 

21 Fig. 9 provides details of operations that update the connections of the switch 

22 matrix for idle trunks and lines to best meet the preferences of the Inbound Routing 

23 Table. Preferably, these operations are performed whenever the configuration of the 
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switch matrix is changed. The operations begin in block 901 whereby the Trunk 
Ownership bytes and the Line Ownership bytes are scanned to identify idle trunks and 
lines (i.e., whose Active Status Field (bit 7) is 'Inactive'), and, for each idle trunk and 
line, setting the Optimization Status field (bit 6) to 'OP'. 

In block 903, a preference scan is made through the Trunk Ownership bytes to 
identify idle trunks whose Optimization Status Field is set to 'OP'. For each one of these 
trunks, the operations of blocks 905 through 911 are performed. 

In block 905, the Inbound Routing Table is accessed to identify the "preferred" 
line for the given trunk. This is accomplished by sequencing through the preference 
levels for the given trunk. If the line at the preference level is available, then it is the 
"preferred" line; otherwise move on to the next preference level. 

In block 907, the Line Ownership byte for the "preferred" line is accessed to 
determine if its Optimization Status Field is set to 'OP'. If not, the operations return to 
block 905 to identify the next "preferred" line in accordance with the preferences of the 
Inbound Routing Table. If, in block 907, the Line Ownership byte for the "preferred" 
line includes an Optimization Status Field set to 'NOP', the operations continue to block 
909. 

In block 909, bits 5-0 of the Line Ownership byte for the "preferred" line is set to 
the trunk ID for the given trunk. In this manner, the scan of the Line Ownership bytes 
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1 and Trunk Ownership bytes that occurs subsequent to block 909 will control the switch 

2 matrix to connect the "preferred" line to the given trunk. 
3 

4 In block 91 1, it is determined whether the scan over the trunks whose 

5 Optimization Status Field is set to 4 OP' is complete. If not, the operation returns to block 

6 903 to perform the operations of blocks 905 through 909 for another idle trunk. If the 

7 scan is complete, the operation ends. In this manner, the connections of the switch matrix 

8 for the idle trunks and lines are updated for inbound call processing. 
9 

10 Fig. 10 provides the details of operations that monitor the quality of service 

1 1 (QOS) of the Internet-based VOIP network and modify the Outbound Routing Tables 

12 accordingly (block 609 of Fig. 6). The operations begin in block 1001 whereby the voice 

1 3 router 58 periodically issues a PING command to one or more servers of the Internet- 

1 4 based VOIP network. Such servers are typically maintained by a VOIP service provider 

1 5 that is responsible for routing VOIP calls from the voice router 58 through the Internet- 

1 6 based VOIP network. The PING command, which is based on the Internet Control 

1 7 Message Protocol, provides a measurement of the round trip time for an IP packet 

1 8 communicated over the LAN/Internet to the VOIP server and back to the voice router 58, 

1 9 and also provides a percentage of packets lost during this round trip. In block 1003, the 

20 packet lost percentage returned by the PING commands are used to generate a heuristic 

21 that represents the characteristic packet loss over the IP connection to these servers. In 

22 block 1005, the heuristic is assigned to a class (for example, Unacceptable, Almost 

23 Unacceptable, Acceptable, Highly Acceptable). In block 1007, it is determined whether 
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1 the user has disabled routing over connections for the class identified in block 1005. If so 

2 the operations continue to block 1009 whereby the Outbound Routing Table(s) are 

3 modified to disable VOIP-based call routing over the VOIP trunks coupled to the voice 

4 router 58 and the operations return to block 1001 to continue monitoring the QOS of the 

5 VOIP network. 
6 

7 If, in block 1007, it is determined that the user has not disabled routing over 

8 connections for the class corresponding to the heuristic, the operations continue to block 

9 101 1. In block 101 1, the Outbound Routing Table(s) are modified, if need be, to enable 

1 0 VOIP-based call routing over the VOIP trunks coupled to the voice router 58, and the 

1 1 operations return to block 1001 to continue monitoring the QOS of the VOIP network. 
12 

1 3 Fig. 1 1 illustrates the parallel routing operations of the voice router 58 of Figs. 1 

1 4 and 2 in accordance with the present invention. The outbound call is initiated over line 1. 

1 5 The outbound call processing operations described above with respect to Figs. 7 A and 7B 

1 6 manipulate the Trunk Ownership bytes and Line Ownership bytes to initially connect the 

1 7 call over PSTN trunk 1 and VOIP trunk 2 (as indicated pictorially by the two arrows). 

18 At a point in the processing (labeled tc C ), the operations identify the preferred trunk as 

1 9 VOIP trunk 2 (for example, it is a long distance call) and disconnect the unwanted PSTN 

20 trunk 1 (as indicated by the end point of the arrow on trunk 1). After this disconnection, 

21 the connections of idle trunks and lines are updated in accordance with the preferences of 

22 the Local Inbound Routing Table as described above with respect to Fig. 9. Such update 
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1 operations are also performed after the outbound call is terminated at time l { (as indicated 

2 by the end point of the arrows on line 1 and trunk 2). 
3 

4 Fig. 12 and 13 illustrate an alternate embodiment of the present invention wherein 

5 the voice router functionality is integrated with voice gateway functionality in a common 

6 system housing 125. In this embodiment, the majority of the components of the system 

7 operate as described above with respect to Figs. 1 through 11. However, the voice 

8 gateway functionality 44' and the microprocessor system 116 share a common Ethernet 

9 interface module 122', which is preferably made accessible to the microprocessor system 

10 1 16 by a data path 126 between the microprocessor system 1 16 and the voice gateway 

11 44'. Note that the voice routing routine 118 may be integrated into a microprocessor 

1 2 system that is part of the voice routing functionality 44'. Moreover, the network-enabled 

1 3 configuration module of the combined device is preferably integrated with the 

14 configuration module 124' of the voice gateway 44'. 
15 

1 6 Fig. 14 illustrates an alternate embodiment of the present invention wherein the 

1 7 voice router 58 is operably disposed between a conventional private branch exchange 

1 8 (PBX) or key telephone system (KTS) 127 and the VOIP Gateway 44 and PSTN NIU 24. 

1 9 The PBX is a customer premises telephone switching system that performs incoming call 

20 termination and outgoing line selection such that the analog telephony devices (e.g., 

21 analog telephones 22a, 22b, 22c, 22d) of the premises share the use of the 

22 telecommunication lines (lines 0 -3) coupled thereto and connected to the PSTN-based 

23 trunks and VOIP-based trunks via the router 58. A special purpose attendant/operator 
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1 console is typically provided on a standard (or optional) basis. Similarly, the KTS is a 

2 customer premises telephone switching that allows the analog telephony devices (e.g., 

3 analog telephones 22a, 22b, 22c, 22d) of the premises to share the use of the 

4 telecommunication lines (lines 0 -3) coupled thereto and connected to the PSTN-based 

5 trunks and VOIP-based trunks via the router 58. Note that a multi-channel trunk (e.g. Tl 

6 trunk) may be used to couple the premises 10' to the local central office 26. In this 

7 configuration, a multi-channel trunk interface (i.e., Tl channel service unit (CSU) and 

8 channel bank) may be used to provide a plurality of trunks that interface to the analog 

9 telephony devices of the premises 10 via the voice router 58 and PBX/KTS 127. The 

1 0 multi-channel trunk interface functionality can be provided by one or more devices that 

1 1 are external to the voice router 58. Alternatively, portions of such functionality may be 

1 2 integral to the voice router 58. In addition, a multi-channel line (e.g., Tl line) may be 

1 3 used to couple the voice router 58 and PBX/KTS 127. In this configuration, a multi- 

1 4 channel line interface may be used to provide a plurality of lines that are coupled to the 

1 5 voice router 58. Such functionality can be provided by one or more devices that are 

1 6 external to the voice router 58. Alternatively, portions of such functionality may be 

1 7 integral to the voice router 58. In this embodiment, the other components of the system 

1 8 operate as described above with respect to Figs. 1 through 11. 
19 

20 Fig. 15 illustrates an alternate embodiment of a voice routing apparatus in 

21 accordance with the present invention, which is particularly suitable for large scale 

22 applications that require the routing of calls over a large number of trunks. In this 

23 alternate embodiment, the routing apparatus 58' will be typically disposed between a 
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1 conventional private branch exchange (PBX) or key telephone system (KTS) 127 and the 

2 VOIP Gateway 44 and PSTN in a manner similar to that shown in Fig. 14. In this 

3 configuration, multi-channel trunks (e.g., Tl trunks) may be used to couple the voice 

4 router 58' to the PBX/KTS system 127, to the VOIP gateway 44, and to the local Central 

5 Office 26, respectively. As is conventional, time slots on the multi-channel trunks are 

6 assigned to carry the signaling data (sometimes referred to as "ABCD" bits) and voice 

7 data for a particular call in digital form. Such signaling can be performed over assigned 

8 time slots (e.g., time slot 16 for a 30-channel El trunk) or over bits carried over the time 

9 slots (e.g., robbed-bits of a 24 channel Tl trunk) as is well known in the communication 

10 arts. Thus, such time slots are analogous to the lines and trunks of the systems previously 

1 1 described herein. In this alternate embodiment, a first multi-channel trunk 101a' is 

1 2 operably coupled between the PBX/KTS system 127 and the RJ48 port 102' of the voice 

13 router 58', a second multi-channel trunk 101b' is operably coupled between the RJ48 port 

1 4 104' of the voice router 58' and the local central office 26 of the PSTN, and a third multi- 

1 5 channel trunk 101c' is operably coupled between the RJ48 port 106' of the voice router 

16 58' and the VOIP gateway 44 of the VOIP network. Trunk interface circuitry 107a', 

17 107b' and 107c' terminates the multi-channel trunks 101a\ 101b', and 101c', 

1 8 respectively, and provides signaling facilities (e.g., On/Off Hook, Ring, DTMF digit and 

1 9 CallerlD signaling) for calls carried over the time slots of the multi-channel trunks. The 

20 signaling facilities of the trunk interfaces provide call related control signals to the 

21 microprocessor-based voice routing routine 1 18 as previously described herein. Space- 

22 time switching logic 108' operates under the control of the microprocessor-based voice 

23 routing routine 1 18 to provide digital switching of voice data over the three multi-channel 



-43- 



NETF-002 

1 trunks 101a', 101b', and 101c. Such digital switching operations are analogous to the 

2 analog switching provided by the switch matrix 108 previously described herein. More 

3 specifically, the space-time switching logic 108' carries out such digital switching by 

4 shifting in time and place the digital data carried over the time slots of the three multi- 

5 channel trunks 101a', 101b', and 101c*. The other components of the system operate as 

6 described above with respect to Figs. 1 through 14. 
7 

8 There have been described and illustrated herein several embodiments of a 

9 system, method and apparatus that provide improved voice routing capabilities. While 

1 0 particular embodiments of the invention have been described, it is not intended that the 

1 1 invention be limited thereto, as it is intended that the invention be as broad in scope as the 

1 2 art will allow and that the specification be read likewise. Thus, while particular data 

1 3 structures and processing operations have been disclosed, it will be appreciated that other 

1 4 data structures and processing operations can be used to realize the improved voice 

1 5 routing capabilities of the present invention as described herein. In addition, while 

1 6 particular applications of the improved voice routing mechanisms and systems based 

1 7 thereon have been disclosed, it will be understood that such mechanisms can be similarly 

1 8 used in other applications and systems. For example, the voice routing mechanisms can 

1 9 be used to route calls over the PSTN Network and calls over a Wide Area Telephone 

20 Service (WATS) trunk. The WATS trunk provides a bulk savings plan for companies 

21 with a high volume of toll calls, such as telemarketing companies. In another example, 

22 the voice routing mechanisms can be used to route calls over different VOIP networks 

23 such as first VOIP network (with guaranteed QOS, reliable service but relatively 
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1 expensive) and a second VOIP network (with no guaranteed QOS but relatively 

2 inexpensive). In another example, the voice routing mechanisms described herein need 

3 not interface to POTS-based analog telephony device, but can readily interface to a wide 

4 variety of telephony devices (and lines), such as IP telephony devices, in order to provide 

5 for intelligent call routing for such devices. Moreover, while particular configurations of 

6 lines, trunks, and multi-channel trunks have been disclosed, it will be appreciated that 

7 other configurations could be used as well. Furthermore, while the present invention as 

8 described above utilizes a microprocessor system to realize call/route processing and 

9 switch control, it will be appreciated that other logic means, including an application 

1 0 specific integrated circuit, programmable logic device or other logic device, can be used. 

1 1 It will therefore be appreciated by those skilled in the art that yet other modifications 

1 2 could be made to the provided invention without deviating from its spirit and scope as 

1 3 claimed. 
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